1. Field of the Invention
This invention relates generally to methods, machine readable media and apparatus for protecting intellectual property (“IP”) that is available to users for evaluation and preventing unauthorized use of such IP in hardware or otherwise after synthesis. More specifically, this invention relates to augmenting electronic designs so that they function properly in a simulation environment, but do not operate correctly in a hardware environment, such as implementation in a programmable device.
2. Description of Related Art
Electronic design automation (“EDA”) systems have become integral to the development of electronic designs for implementation in devices such as programmable logic devices (PLDs) and field programmable gate arrays (FPGAs). An EDA system provides various tools that receive and convert a user's high-level representation of an electronic design to a form suitable for programming the programmable device. EDA systems may include tools for design entry, compilation, synthesis, mapping, verification, generating a programming file, etc. In addition, EDA systems typically include a simulation tool for confirming that the electronic design is likely to operate as intended. The design of even the simplest of these devices typically involves generation of a high level design, logic simulation, generation of a network, timing simulation, etc.
During the process of creating an electronic design, a user may employ one or more reusable IP cores. These are predefined and preverified functional blocks for performing well-defined tasks that may be incorporated into a user's electronic design. In some cases, they may define an entire electronic design itself. Frequently, they are configurable by a user who can specify one or more parameters appropriate for the desired application. They are designed to work well with existing EDA tools so that users can easily input them into their electronic designs. IP cores may be viewed broadly to include “megacores,” “megafunctions” and other predefined logic blocks for implementation in programmable devices. Megacores define large complex functional blocks such as microprocessors and sophisticated communications blocks such as a block for terminating a trunk protocol on a fiber optic link. Megafunctions define smaller functional blocks such as a DSP filter, multiplier, or FIFO memory. Collections, or libraries of simple parameterized megafunctions are available. One example is the library of parameterized modules (“LPM”) developed under the guidance of the EDIF association. A variety of these IP cores are available from Altera Corporation of San Jose, Calif.
In the modern EDA environment, IP core vendors typically allow users to evaluate the IP cores without charge or authorization (for example, a license) before deciding whether to implement them into a final design. Therefore, the vendors provide their cores in a form that allows both evaluation and compilation to a final hardware programming file. Evaluation requires simulation on one of the many available EDA simulation tools. Therefore an IP core vendor typically provides a customer with two forms of a core: (1) a programming version in the form of source code and/or synthesized netlist for compiling the IP core to a programming file using a particular EDA tool (e.g., Quartus available from Altera Corporation of San Jose, Calif.); and (2) a simulation version that can be executed on a specific third party simulator to evaluate the IP core.
While a user may evaluate one or more IP cores for free in a simulation environment, a user must have authorization from the IP owner to implement an IP core in a hardware environment such as a target hardware device. Vendors must be concerned with the possibility of unauthorized use of their IP cores, which may occur in various ways. In one example of unauthorized use, the user converts the programming version of the IP core to a programming file and then programs hardware devices without a license from the IP core vendor. In another example, a user ports an electronic design containing the IP core to a competitor's hardware platform.
In order to address the issue of unauthorized use of IP cores in hardware environments, both the programming version and the simulation version of a core must be protected. One approach to protecting the programming version involves encrypting the IP core's source code and/or synthesized netlist. Another approach is to verify the existence of a licensing file before generating a programming file for the target hardware device. These approaches do a good job of protecting the programming version of an IP core from unauthorized use. However, they are not practical for protecting the simulation version of the core.
While the programming version can be designed for use with a single EDA platform (for example, Altera's Quartus), the simulation version typically must work with many different simulation tools. For example, Quartus and other EDA platforms work with an array of different simulation tools, each of which may be provided by a different vendor. Examples of simulation tools include ModelSim by Mentor Graphics Corp. (Wilsonville, Oreg.); Verilog-XL and NC-Verilog simulators by Cadence Design Systems, Inc. (San Jose, Calif.); and VCS simulator by Synopsys, Inc. (Mountain View, Calif.).
Because the simulation version of an IP core must work with a variety of different simulation tools, security features must work with each tool. One could provide a simple source code version of the IP core for simulation (for example, Verilog), which could be compiled to the appropriate machine code for any of a number of different simulators. But this approach provides little, if any, security. An unscrupulous user could modify the source slightly to allow compilation to a programming file that would circumvent the licensing requirements of the IP vendor.
To improve security, a vendor could provide precompiled versions of the simulation version for each of the available simulation tools on the market. Unfortunately, this is not practical. The vendor would need to maintain updated versions of the IP for each of the third party simulation tools, which can run on various computer platforms, thus requiring a separate compiled version of the IP for each combination of simulator and hardware platform. The problem is exacerbated by the myriad of configuration possibilities for each IP core (which usually depend on user settings). The IP vendor might have to provide a separate compiled version of the core for each potential configurations (on each of the simulator-hardware combination). Consequently, it would be unfeasible for a vendor to maintain a full range of simulation versions.
Another approach to providing simulation versions gives the actual source code of the simulation version to trusted users only (for example, employees of large companies known to maintain close control over the IP). Unfortunately, this limits the market available to IP vendors. In yet another approach, the IP core vendor provides an equivalent behavioral model of the simulation version. A behavioral model cannot be compiled to produce a working program file for implementing the design on hardware devices. Unfortunately, this approach has its drawbacks in that it usually will not produce a model that is cycle and bit accurate.
There are some EDA system tools such as “VIP” (Visual IP available from Summit Design (Burlington, Mass.)) that attempt to address the problem of making secure simulation versions of IP cores. VIP can generate a secure simulator-independent simulation version, but requires use of various special purpose VIP proprietary tools, such as translation programs and adaptors, which must be purchased by the user. Obviously, an IP vendor would prefer not to force potential customers to purchase third-party tools that protect the vendor. Further, VIP-generated simulation versions are generally large, slow, and require PLI/FLI setup that is difficult to use and is time consuming.
A typical design cycle (using, for example, Altera's OpenCore technology) is shown in FIG. 1A. A designer creates an initial block diagram 110 and subsequently identifies and evaluates (for example, in terms of functionality and the range of parameterization) potential IP cores and/or megafunctions available for use in the anticipated system 120. The designer then can obtain authorized simulation versions of any IP to be used from the IP's owner or agent 130. After finding the appropriate megafunction(s), the designer generates (typically with the assistance of simulation generation software, such as Altera's SimGen) a simulation version of the user's designed logic 140. The user may then test the designed logic in a simulation environment by simulating performance 150 within the anticipated circuitry and system.
Once simulation and validation are completed, the IP used can be synthesized for use in hardware 160. To incorporate a design into a programmable device, the design that has been simulated needs to be synthesized to generate a design that can be implemented in a programmable device. After implementing the designed logic in hardware, the designed logic may then be tested in the hardware environment 170.
The goal of many IP owners has been to create designs and release them to customers in a form that allows customers to simulate a design using a software model (for example, a Verilog or VHDL model in EDA simulators) without telling customers too much about what the core is or that can be used in an EDA synthesis tool. One option has been to create model that is synthesizable, but not desirable from a performance perspective in a hardware device (for example, a design that runs too slowly when synthesized and implemented in a hardware device).
Another approach has been to precompile a design in a form that cannot be reverse engineered and is not human readable. In these situations, the original IP is precompiled by a trusted party, such as the IP owner, for use in simulation tools only. One drawback to this method is that it is very time consuming for the party doing the conversion and it is inconvenient for would be users of the design(s). This also can result in designs that are very cumbersome for customers to use and change, though some models can be parameterized to allow changes by customer.
Parties also have started using simulation generators, which are software tools that synthesize original IP into simulatable models. Such simulation generators obfuscate and “flatten” the IP, making it difficult, though not impossible, for humans to read and decipher the design. For example, during obfuscation, clues for understanding the model (for example, structures, names, node names, register names, function names) are thrown away and are replaced with machine-generated names that are random terms without any connection to functions, etc. This basically is a netlist dump in protected form that is useful for simulation, but is only marginally useful for synthesizing the design. Flattening the IP involves altering and/or removing boundaries and other demarcations that likewise can assist in understanding the operation and structure of programmed logic.
A simulation generator does not change the model itself. Simulation generators do not perform any transformations on an original design. Instead, the simulation design is a direct copy of the original design that has been obfuscated, flattened and had unnecessary parts and components reduced and/or eliminated. Despite these efforts to protect the interests of IP owners, some users can still synthesize designs and implement them on hardware devices, without authority from the IP owners.
Techniques that permit thorough simulation and other development of digital systems and devices by designers and users, while making unauthorized synthesis and operation of these designs in a hardware environment more difficult would protect the proprietary interests of the owners of the intellectual property incorporated in such systems and devices and would represent a significant advancement in the art.